Date: Sat, 17 Apr 93 04:30:03 PDT 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #105 

To: packet-radio 


Packet-Radio Digest Sat, 17 Apr 93 Volume 93 : Issue 105 


Today's Topics: 
AMPR Backbone 
ls -1R uscd.edu: /hamradio 
Poor Man's Packet/Article Wanted (2 msgs) 
Poor Man's Packet Design/Article wanted 
Single chip receiver for FSK? (2 msgs) 
Welcome to rec.radio.info! 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 16 Apr 93 13:21:21 GMT 

From: netcomsv! gnct! thomason@decwrl.dec.com 
Subject: AMPR Backbone 

To: packet-radio@ucsd.edu 

Hello, 


I am interested in the structure of ampr network, and would like to 
take a look at the map of AMPR Backbone at the world top level. 


Since I have no direct connecton to Internet, I cannot find it in 
any node. 


Could anyone who has it put it here ? 


Thanks in advance. 


thomason@gnct.com (thomason) 
GloCom BBS - (852)4925025 


Date: 16 Apr 93 13:21:20 GMT 

From: netcomsv! gnct!thomason@decwrl.dec.com 
Subject: ls -1R uscd.edu:/hamradio 

To: packet-radio@ucsd.edu 


Hello, 


I am very interested in the directory listing of uscd.edu: /hamradio 


Could anyone help me to get and put it here ? 
Thanks in advance. 
73 DE VS6YHI 


thomason@gnct.com (thomason) 
GloCom BBS - (852)4925025 


Date: 16 Apr 93 19:42:06 GMT 

From: vnet.IBM.COM@uunet.uu.net 

Subject: Poor Man's Packet/Article Wanted 
To: packet-radio@ucsd.edu 


>>I am looking for a design for or a reference to an article on a design 


>>for a Poor Man's Packet TNC. 


>>I would like to construct a Packet TNC as a project. 


> For a Mac or IBM clone? 
For an IBM clone... 


Wayne Salhany 


Internet: 


salhany@vnet.ibm.com 


Date: 16 Apr 93 20:32:13 GMT 

From: ogicse!uwm.edu! zaphod.mps.ohio-state.edu!howland.reston.ans.net! 
sol.ctr.columbia.edu!news.cs.columbia. edu! amb@network.UCSD.EDU 
Subject: Poor Man's Packet/Article Wanted 

To: packet-radio@ucsd.edu 


salhany@vnet.IBM.COM (Wayne Salhany) writes: 
>I am looking for a design for or a reference to an article on a design 
>for a Poor Man's Packet TNC. 


An article with everything you need to know to make one (including PCB 
drawings) was in 73 a few years ago. Can't find the specific reference, 
but that's what indices are for... 


andrew 


Date: 16 Apr 93 16:33:36 GMT 

From: ogicse!uwm.edu!ux1.cso.uiuc.edu!news.iastate.edu!vlsi4! jvp@network.UCSD.EDU 
Subject: Poor Man's Packet Design/Article wanted 

To: packet-radio@ucsd.edu 


In <9304152120.AA17186@relay2.UU.NET> sforbes@vnet.IBM.COM writes: 


>I am looking for a design for or a reference to an article on a design 
>for a Poor Man's Packet TNC. 


>I would like to construct a Packet TNC as a project. 


For a Mac or IBM clone? 


| Jim Van Peursem - Ph.D. Student - Ham Radio -> KEOPH | 
| Department of Electrical Engineering and Computer Engineering | 
| Iowa State University - Ames, IA 50011 

| internet - jvp@iastate.edu -or- jvp@cprel1.ee.iastate.edu | 


Date: Fri, 16 Apr 1993 15:12:57 GMT 

From: news.cerf.net!pagesat!spssig.spss.com!uchinews! linac! uwm.edu! 
zaphod.mps.ohio-state.edu!swrinde! gatech!hubcap!ncrcae!ncrhub2! law7! 
jra@network.UCSD.EDU 

Subject: Single chip receiver for FSK? 

To: packet-radio@ucsd.edu 


My next project is to come up with an IF/detector module for fast -- 112 
to 250 kB/sec -- packet radio use. No fancy modulation scheme, just 
wide FSK for use at 902 or 1296 MHz. 


I'm a bit familiar with the Motorola 3362 chip, but I wonder if there 
are newer designs that might work at higher input frequencies. 


My goal is to come up with an inexpensive design for a receiver "back 
end" with IF input on one end and an FSK demondulator on the other. I'm 
particularly interested in ways to use a higher IF than 10.7 -- do any 
current chips work up to, say 150MHzZ with internal downconversion so a 
normal IF filter can be used? 


Any suggestions? 


John 
John R. Ackermann, Jr. Law Department, NCR Corporation, Dayton, Ohio 
(513) 445-2966 John. Ackermann@daytonoh.ncr.com 


Packet Radio: ag9v@n8acv.oh tcp/ip: ag9v@ag9v.ampr [44.70.12.232] 


Date: 16 Apr 93 22:21:37 GMT 

From: noao!asuvax! gatech!howland.reston.ans.net!zaphod.mps.ohio-state.edu! 
sdd.hp.com!col.hp.com!news.dtc.hp.com!srgenprp! glenne@arizona.edu 

Subject: Single chip receiver for FSK? 

To: packet-radio@ucsd.edu 


gen Ackermann x 2966 (jra@law7.DaytonOH.NCR.COM) wrote: 

: My next project is to come up with an IF/detector module for fast -- 112 
: to 250 kB/sec -- packet radio use. No fancy modulation scheme, just 

: wide FSK for use at 902 or 1296 MHz. 


: I'ma bit familiar with the Motorola 3362 chip, but I wonder if there 
: are newer designs that might work at higher input frequencies. 


: My goal is to come up with an inexpensive design for a receiver "back 

: end" with IF input on one end and an FSK demondulator on the other. I'm 
particularly interested in ways to use a higher IF than 10.7 -- do any 

: current chips work up to, say 150MHz with internal downconversion so a 
normal IF filter can be used? 


: Any suggestions? 


: John 


What you describe is very close to what I built and described in the 
10th ARRL Computer Network Conference proceedings. 


I built 10 watt FSK transceivers at 904 MHz. They are essentially 
double conversion transverters with digital mod and demod at 29 MHz. 
The receiver uses the MC13055 which is the same FSK receiver chip I used 
previouslyu in the 2 Mbps 10 GHz data link I first published in Ham 
Radio and which is now also in the ARRL handbook. 


The MC3356, which includes a VHF converter section, could also be used 
at these speeds. There is a newer and perhaps slightly improved design 
of this (the MC13056 if I remember rightly). 


While using this would have let me reduce the "external" IF count on 
receive, it didn't really offer all that much help on transmit so I 
didn't bother with it. 


The radios I built were first designed and built for 512 kbps in a 2 
MHz channel but later reduced to half that. These 256 kbps radios 
actually have done quite well in across-the-bench tests at 384 kbps and 
speed is pretty much a function of filter design. Handling the data 
stream is another matter entirely. 


Some of the existing radios are currently deployed on hilltops ina 
"beacon" test mode. While there is not yet end-end two-way data flow 
due to lack of resources to debug software for the digital hardware (MIO 
also shown in the CNC proceedings), data is perfect copy at négn. Even 
though the data clock is currently at about half speed, the a 2+ kbytes 
of the test text (chapter 55 of Isaiah) takes only a little over 1/8 of 
a second. 


I've been hoping that someone would get interested enough to step in 
and get involved in writing code to make the whole thing usable (Borland 
IDE environment with remote debugging possible as mentioned in the 
proceedings) but to date a couple of us have been on our own and running 
low on resources of time, money and energy. 


If anyone in the SF bay area wants to check it out there is also a CW 
ID after the text on the mark side at 904.740 MHz from beacons on Sonoma 
Mtn and Black Mtn (overlooking Si valley). The antenna is horizontally 
polarized. 


I guess in retrospect my suggestions are that this is a fairly costly 
approach if the radios are intended for users rather than backbones and 
you might want to carefully consider your "target". If you can't 
arrange your paths such that you have complete line-of-sight I think 
you'll want to address the inter-symbol-interference caused by 
multipath and probably link C/N budgets if paths are very far from LOS. 


For more details, see the 10th CNC. I'm currently working on a spread 
spectrum, direct conversion design to address some of these problems. 
I'd be glad to help as I can with any design problems. 


73 
Glenn Elmore négn 


N6GN @ K3MC 
amateur IP: glenn@SantaRosa.ampr.org 
Internet: glenne@sr.hp.com 


Date: Fri, 16 Apr 1993 14:14:00 MST 

From: hellgate.utah.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu! 
sol.ctr.columbia.edu!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!ersys! 
veémgs!rec-radio-info@@dog.ee.1lbl. gov 

Subject: Welcome to rec.radio.info! 

To: packet-radio@ucsd.edu 


Archive-name: radio/rec-radio-info/welcome 
Last-modified: $Date: 1993/04/09 20:30 $ 
Version: $Revision: 1.03 $ 


xxk Welcome to rec.radio.info! «xx 


Welcome to rec.radio.info, a group that aims to provide a noise-free source 
of information and news for the entire rec.radio hierarchy. 


Two introductory articles about rec.radio.info are posted to the group and 

to news.answers every two weeks. You are now reading the first article, which 
explains what rec.radio.info is, and answers some Frequently Asked Questions. 
The second article is titled "Submission Guidelines", and you only need to 
read it if you want to submit an article to rec.radio.info. 


-- What is the purpose of rec.radio.info? 


The purpose or charter of rec.radio.info is to provide the Usenet community with 
a resource for information, news, and facts about any and all things radio. 


All the other rec.radio groups are intended for discussions and general chit 
chat about radio. Rec.radio.info will contain informational, factual articles 
only. Follow-ups are redirected to an appropriate other group, and further 
discussion (if any) will not take place in rec.radio.info. 


In order to ensure that rec.radio.info contains only appropriate articles, it 
was decided to create the group as a moderated newsgroup. 


-- Why are messages almost always cross posted to rec.radio.info? 


It provides a "tag" for each article to be assembled into a filtered 
presentation in rec.radio.info (even with cross-posting, only one message, with 
a unique Message-ID, is propogated across the net). This tag also facilitates 
a pre-existing method of dropping or cancelling the articles locally within the 
discussion groups if you don't want to see them. This accommodates individuals 
who want to separate the bulletins from the discussions, discussions from the 
bulletins, as well as those who are adamant about not reading another 

newsgroup and wanted to see everything all in one basket. 


With the total size of Usenet (in number of newsgroups and total traffic) 
doubling every year or so, this is no insignificant contribution to reducing 
information noise and chaos. Making the discussion groups a catch-all, and 
making extra newsgroups filters on that catch-all, is also the most realistic 
way to implement such a scheme (It's not intuitively obvious what the charter, 
contents, and general appropriate topics for each and every newsgroup are. 
Seeing FAQ's and charter/intro postings in the home newsgroup is beneficial 
for new readers). 


By cross-posting one only is adding a few tens of bytes to each bulletin (to 
specify the extra group on the Newsgroups line), but are adding the capability 
for very powerful filtering features available on most news servers, 
listservers and readers. Your local news guru could probably explain these 
features in more detail. 


In rn, for example, according to Leanne Phillips in her rn kill-file FAQ, add 
a line of the form: 

/Newsgroups:.*[ ,]rec\.radio\.info/h:j 
either in ~/News/KILL (if you don't want to see rec.radio.info articles 
anywhere) or ~/News/rec/radio/amateur/misc/KILL (if you don't want to see them 
just in rec.radio.amateur.misc). The latter method means your kill file will 
only be consulted during rec.radio.amateur.misc (and hence runs more 
efficiently), and will probably work for most people. 


In nn, according to Bill Wohler in his nn FAQ, add a line of the form: 
rec.radio.info:!s/:% 
in ~/.nn/kill (if you don't want to see rec.radio.info articles anywhere), or 
put the following lines: 
sequence 
rec.radio.info 
rec.radio. 
at the end of ~/.nn/init in order to see all the rec.radio.info bulletins first, 
then read the remaining rec.radio.* without the bulletins. 


-- What is a 'follow-up', and what does 'moderated' mean? 


If you are new to Usenet and are not familiar with the terminology, you might 


want to read the general introductory articles found in the newsgroup 
news.announce.newusers. Doing so will make your life on the net much easier, 
and will probably save you from making silly beginner's mistakes. 


If you think that at this moment you are reading an echo, a conference, or 
a bulletin board, I'd also strongly suggest a trip over to 
news.announce.newusers. 


For the rest of this article, I will assume you have a basic knowledge of 
Usenet terminology and mechanics. 


-- OK, so now I know what 'moderated' means. Tell me more. 


Rec.radio.info is a moderated newsgroup, which means that all articles 
submitted to the group will have to be approved by the moderator first. 


The current moderator of the group is Mark Salyzyn. Submissions to 
rec.radio.info can be posted, or e-mailed to: 


rec-radio-info@ve6émgs.ampr.ab.ca 


Comments, criticisms, suggestions or questions about the group can be e-mailed 
to: 
rec-radio-request@ve6mgs.ampr.ab.ca 


But before you do so, please be sure to check out the "Submission Guidelines" 
article. 


The influence of the moderator should be minimal and of an administrative 
nature, consisting chiefly of weeding out obviously inappropriate articles, 
while making sure correct headers etc. are used for the appropriate ones. 


-- What type of material is considered inappropriate? 


There are three broad categories of articles which will be rejected by the 
moderator: 


1) Requests for information: rec.radio.info is strictly a one-way street. I 
receive information in my mailbox; I then post it to rec.radio.info. 
Requests for specific information belong in the normal discussion newsgroups. 
If your request gets answered, you might consider passing the answer on to 
rec.radio.info, though. Especially if you can edit it into a informational, 
rather than a discussion, format. 


2) Obvious discussion articles, or articles that appear unsubstantiated. 


3) Commercial stuff: a relatively unbiased test of a radio product would be 
accepted, but any hint of for-profit might be reason for rejection. For three 


reasons: This is not the purpose of the list, for-profit is a controversi 
topic, and this list may be passed onto Amateur Packet Radio (where 
for-profit is prohibited except under certain provisos). 


rec.radio.swap may be more deserving of the posting in any matter. 


Similarly, copyrighted material generally cannot be used. If it's TRULY 
worthwhile to the net, I would recommend obtaining permission from the 
copyright holder. Please note the source, and if permission was given. 
reserve the right to make the final decision concerning appropriateness i 
all situations. In most cases, a brief summary of, or pointer to, the 
copyrighted information may be all I can allow. 


-- I do not have access to news, how can I get the information posted to 
rec.radio.info? 


brian@UCSD.EDU (Brian Kantor) has kindly supplied a mail list server for 
rec.radio.info. Non of the articles will be digested, due to their size, so 


you will receive individual mailings for every article posted to the group. 


Mail sent to radio-info@ucsd.edu will be forwarded to the moderator and 
thus is an alias to rec-radio-info@ve6émgs.ampr.ab.ca 


To subscribe and unsubscribe via the listserver; the format for that is 


sub address radio-info 
unsub address radio-info 


where ‘address' is your full mailing address. Send this request to 


listserv@ucsd.edu 


al 


I 
n 


Note that the server will automatically delete any address that bounces mail. 


If you leave the address portion blank, it will try to deduce your address 
from the mail headers. This may not work if you are on bitnet, milnet or 
some other non-Unix host, so it is recommended to put your return address 
in any case. For example: 


sub mymailbox@myhost.mydomain.mil radio-info 
or 

sub MEMEMEOQ1@DMBHST.bitnet radio-info 
or something like that. 


-- Will the material appearing in rec.radio.info be archived somewhere? 


Yes. Still firming up details at the moment but here is a preliminary list: 
- unbc.edu as maintained by Lyndon Nerenberg <lyndon@unbc.edu> 


- nic.funet.fi maintained by Risto Kotalampi <rko@cs.tut.fi> 
saved to /pub/dx/text/rec.radio.info currently stored as 
numbered files. 


Effectively this means that anything you post to rec.radio.info will be 
permanently stored, so your work will not be lost. 


-- I have a regular posting with timely information, is there a way to 
speed up it's delivery, or automate for more convenience? 


Yes, there is! It may take a bit of chatter with the moderator, but we are 
willing to take responsible people and provide them the means of posting the 
articles directly from their site. We will try everything we can as we fully 
realize that DX (distant signal) and astronomical data can be somewhat 
transitory. We are also willing to allow regular posters of information the 
same courtesy, even if the information is not as timely. 


We refer to this as self-moderation, which is partly based on the model for 
news.answer. This requires co-operation and good will to be beneficial to 
the community in the rec.radio hierarchy. 


I suggest reading the posting guidelines for more information. I am open to 
suggestions. 


I thank the following individuals for their input into this article: 
rec.music.info moderator Leo Breebaart rec-music-info@cp.tn.tudelft.nl 
rec.radio.broadcasting moderator Bill Pfeiffer wdp@gagme.chi.il.us 
Paul W. Schleck, KD3FU pschleck@unomaha.edu 
Tan Kluft, KD6EUI ikluft@uts.amdahl.com 


Mark Salyzyn -- Moderator rec.radio.info 

Submissions to: rec-radio-info@veémgs.ampr.ab.ca 

Administrivia to: rec-radio-request@ve6mgs.ampr.ab.ca 

* Requests for information do xnot*x belong in rec.radio.info x 


End of Packet-Radio Digest V93 #105 
KI KKK KKK KK IKK K KAKA AKEK ERK 


